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PREFACE 


» 


The  purpose  of  IDA  Memorandum  Report  M-552,  “Software  Technology  Development 
and  Deployment  Plan  for  the  DoD  Technology  Base,”  is  to  document  the  findings  and  results  of 
a  workshop  study.  The  workshop  participants  were  asked  to  place  primary  focus  on  software 
technology  base  actions  and  recommendations  that  might  enhance  the  Department  of  Defense’s 
ability  to  deploy  software  intensive  weapon  systems. 

This  document  is  intended  to  fulfill  the  objective  of  Task  Order  T-D5-627,  A  Software 
Technology  Development  and  Deployment  Plan  for  the  DoD  Technology  Base,  and  to  serve  as 
an  additional  input  for  the  next  Deputy  Director  of  Defense  Research  and  Engineering 
(Research  and  Advanced  Technology)  (DDDRE  (R&AT))  Program  Objective  Memorandum 
(POM)/budget  review  in  mid-FY1989.  The  report  focuses  on  some  of  the  potential  actions  that 
the  DDDRE(R&AT)  may  consider  to  improve  the  development  and  deployment  of  software 
technology  in  systems. 

An  earlier  draft  of  this  report  was  provided  to  all  of  the  workshop  participants  for  review 
and  comment.  The  final  draft  of  the  report  was  reviewed  within  the  Computer  and  Software 
Engineering  Division  (CSED)  by  T.  Mayfield,  S.  Nash,  and  C.  Linn. 


i  x 


EXECUTIVE  SUMMARY 


This  study  was  requested  by  the  Deputy  Director  of  Defense  Research  and  Engineering 
(Research  and  Advanced  Technology)  (DDDRE  (R&AT)),  to  develop  a  Software  Technology 
Development  and  Deployment  Plan  for  the  DoD  Technology  Base,  A  series  of  three  workshop 
meetings,  chaired  by  Dr.  Ruth  Davis,  was  held  in  November  1988,  December  1988  and  early 
January  1989.  The  workshop  participants  were  asked  to  place  primary  focus  on  actions  that 
could  enhance  the  Department  of  Defense’s  ability  to  deploy  software  intensive  weapon  systems, 
to  capitalize  on  the  findings,  conclusions,  and  recommendations  of  previous  DoD  software 
studies,  and  to  draw  from  their  own  personal  experiences. 

This  study  attempted  to  take  a  different  approach  than  previous  software  studies  by 
addressing  those  common  “user”  problems  directly  related  to  deployment  of  operational 
software  intensive  weapon  systems.  The  recommendations  are  based  on  the  findings  and 
perceptions  resulting  from  the  three  workshops.  The  workshop  participants  reiterated  that  DoD 
has  a  number  of  operational  systems  with  critical  software-related  problems  and  that  the 
software-related  cost  of  maintenance  and  support  for  DoD  systems  is  rising  dramatically. 
Although  DoD  has  asked  various  experts  to  address  these  growing  software-related  problems  on 
several  occasions,  to  date,  the  majority  of  their  recommendations  have  not  been  implemented. 
The  participants  felt  that  a  lack  of  a  central  DoD  focus  on  software-related  issues  has 
contributed  to  the  relatively  slow  resolution  of  software  problems  across  DoD.  Finally,  they  felt 
that  applying  research  and  development  to  software-related  technology  problems  currently 
experienced  on  deployed  systems  would  not  only  permit  early  realization  of  software  technology 
enhancements,  but  through  the  resulting  demonstrated  benefits,  would  also  stimulate  more 
advanced  software  technology  applications  across  systems  and  Services. 

The  workshop  resulted  in  five  key  findings  and  recommendations  for  the  DDDRE 
(R&AT)  that  address  specific  technology  base  efforts  as  well  as  DoD  policy/management 
infrastructure  changes  that  should  be  considered  for  immediate  action. 


a.  Deployed  Military  Software  Improvement  Programs:  Establish  a  comprehensive  approach 
for  improving  military  software  during  deployment.  The  focus  should  be  on  the  phases  of 
the  software  life  cycle  that  have  the  most  influence  over  the  deployment  of  software 
intensive  systems.  The  approach  should  include  a  series  of  demonstration  projects  that 
focus  on  developing  system  upgrades  for  operational  software  intensive  weapon  systems 
currently  experiencing  critical  software  difficulties. 

b.  Software  Technology  Funding  Support:  The  Service  Laboratories’  software  technology 
base  programs  and  the  DoD  Software  Initiative  (Ada,  STARS  (Software  Technology  for 
Adaptable,  Reliable  Systems),  and  SEI  (Software  Engineering  Institute))  should  continue 
to  be  supported  and  fully  funded  for  FY  1990.  Since  the  rate  of  software  technolog)' 
evolution  has  not  kept  pace  with  DoD  weapon  systems’  growing  requirements  for  more 
software  with  increasing  complexity,  DoD  should  reassess  the  software  technology  base 
requirements  for  FY  1991  to  ensure  that  the  software  technology  base  funding  priority  is 
increasing  commensurate  with  the  trend  of  increasing  software-related  deployment  costs. 

c.  Generic  Software  Technology  High  Priority  Efforts:  The  Services  and  Agencies  should  be 
tasked  to  establish  “lead  agents”  for  selected  critical  software  technology  areas.  The  lead 
agents  should  be  carefully  selected  from  within  the  Services  for  their  expertise  in  software- 
related  disciplines.  The  primary  functions  of  the  software  lead  agents  would  be  to  identify 
Service  software  technology  related  problems  and  requirements,  to  share  software 
technology  information  with  DoD  and  the  Services,  and  to  stimulate  advr...c^d  software 


technology  application  across  Services  and  program  offices. 

d.  Recommendations  of  Previous  Studies:  The  Science  and  Technology  Committee  of  the 
Defense  Acquisition  Board  should  be  tasked  to  review  the  recommendations  of  the 
September  1987,  Defense  Science  Board  Task  Force  on  Military  Software  and  to  sponsor 
and  promote  their  implementation. 

e.  DoD  Software  Responsibility  and  Authority:  Establish  an  immediate  initiative  to 
consolidate  DoD  software  and  computer  policy,  management,  and  oversight  within  a 
structured  forum  (with  both  responsibility  and  authority)  that  is  commensurate  with 
software  technology’s  growing  importance.  The  following  were  recommendations 
developed  during  the  workshop  to  specifically  address  this  very  complex  software-related 
responsibility  and  authority  problem. 

1.  Establish  a  Director  of  Military  Software  Improvement,  within  the  Office  of  the 
Under  Secretary  of  Defense  (Acquisition),  responsible  for  identifying,  managing, 
integrating  and  implementing  software  deployment  policy. 

2.  Establish  a  committee  under  the  co-chairmanship  of  the  Director  Defense  Research 
and  Engineering  and  the  Assistant  Secretary  of  Defense  (Production  and  Logistics) 
with  representation  from  the  Assistant  Secretaries  of  the  Services.  The  committee 
will  provide  a  direct  forum  for  addressing  policy  and  program  issues  that  transcend 
Service  and  Agency  requirements. 

3.  Develop  and  distribute  a  software  responsibility  and  authority  guide.  The  intent  of 
the  guide  should  be  to  clearly  outline  the  various  software-related  roles  and 
responsibilities  within  OSD  and  permit  a  greater  understanding  of  the  current 
software  policy,  review,  coordination  and  oversight  related  processes  within  DoD 
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This  report  documents  an  Institute  for  Defense  Analyses  (IDA)  study  conducted  under 
Task  Order  T-D5-627  for  the  Deputy  Director  of  Defense  Research  and  Engineering  (Research 
and  Advanced  Technology).  The  objective  of  the  study  was  to  generate  one  or  more  options  for 
a  software  technology  development  and  deployment  plan  for  the  DoD  Technology  Base. 
Subordinate  goals  of  the  study  were  to  capitalize  on  the  results  of  previous  software  studies  while 
focusing  on  operationally  manifested  software  technology  problems,  and  to  serve  as  an 
additional  input  for  the  next  DDDRE(R&AT)  Program  Objective  Memorandum  (POM)/budget 
review  in  mid-FY  1989. 

1.1  Scope 

The  study  was  performed  via  a  series  of  three  workshop  meetings  conducted  by  IDA  and 
chaired  by  Dr.  Ruth  Davis.  The  workshop  participants  were  selected  for  their  in-depth  technical 
background  and  personal  expertise  over  a  wide  range  of  software-related  technologies  including 
software  intensive  weapon  system  applications.  Appendix  A  includes  a  list  of  the  workshop 
participants. 

The  first  workshop  focused  on  military  requirements  for  computer  and  software 
technologies,  with  special  emphasis  on  system  operational  deployment  and  long-term  support 
requirements.  The  second  workshop  addressed  opportunities  for  improving  software-related 
technology  deployment  This  workshop  focused  on  current  DoD  software-related  programs  and 
on  the  findings  of  recent  studies  citing  DoD  software-related  problems.  The  third  workshop 
focused  on  software  intensive  weapon  systems  deployment  and  support  problems  as  viewed  from 
a  user’s  perspective.  Because  there  appeared  to  be  a  number  of  studies  (along  with  measurable 
amounts  of  work)  addressing  software  technology  base  issues  relative  to  future  systems,  the 
workshop  participants  narrowed  the  study  to  focus  on  software  technology  problems  that 
directly  relate  to  current  deployment  of  operational  weapon  systems. 

In  the  context  of  this  report,  software  technologies  were  defined  to  include  software 
products  (tools  and  packages)  as  well  as  related  development  and  support  technologies 
(programming,  documentation,  environments,  testing,  etc.).  Software  deployment  was  defined 
as  the  development,  use,  management,  modification  and  support  of  software  systems. 
Therefore,  software  deployment  as  used  in  this  report  includes  system  software  development, 
operational  prototyping  and/or  test-bed  development,  operational  test  and  evaluation,  operation 
and  maintenance,  and  upgrading  and/or  updating. 

From  this  perspective,  the  workshop  participants  were  asked  to  identify  actions  that 
would  enhance  DoD’s  ability  to  deploy  software  intensive  weapon  systems.  Additionally,  the 
participants  were  chartered  to  capitalize  on  previous  software  studies.  Recommended  actions 
were  to  be  based  on  current  military  requirements,  ongoing  and  planned  development,  advanced 
technology  software  efforts,  and  current  policy  and  management  philosophies.  In  particular,  the 
“military  software”  operational  objective  adopted  was  the  “deployment”  of  software  in  weapon 
and  support  systems  that  measurably  meets  or  exceeds  operational  requirements,  delivery 
schedules,  product  quality  specifications,  maintenance  service  demands  (including  development 
necessary  for  upgrading),  and  cost  targets. 
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2.  BACKGROUND 

2.1  Interdependencies  of  Software  Technology  and  Military  Capabilities 

Software  is  an  essential  element  of  technologically  superior  weapon  systems  and  provides 
a  major  contribution  to  DoD  military  capabilities  found  in  ground,  sea,  air,  and  space  systems. 
“The  size  and  complexity  of  this  software  has  been  growing  exponentially,  because  designers 
choose  to  implement  needs  of  the  increased  functional  complexity  of  these  systems  in  software” 
[Zraket  et  al.  88,  1].  In  addition,  the  Defense  Science  Board  further  substantiates  this 
observation.  “The  ‘smarts’  of  smart  weapons  are  provided  by  software.  Software  is  crucial  to 
intelligence,  communications,  command,  and  control.  Software  enables  computerized  systems 
for  logistics,  personnel,  and  finance.  The  ‘chief  military  software  problem’  is  that  we  cannot  get 
enough  of  it,  soon  enough,  reliable  enough,  and  cheap  enough  to  meet  the  demands  of  weapon 
systems  designers  and  users.  Software  provides  a  major  component  of  U.S.  war-fighting 
capability”  [DSB  Sept.  87,  6].  As  a  consequence,  more  and  more  of  DoD’s  weapon  systems 
are  directly  dependent  on  advancing  software  technologies.  Once  software  intensive  systems  are 
deployed,  DoD  must  possess  the  critical  capabilities  to  maintain  and  evolve  the  software  in  these 
weapon  systems  throughout  the  life  cycle. 

2.2  Highlights  of  the  Life  Cycle 

The  life  cycle  of  software  is  inextricably  tied  to  the  life  cycle  of  the  weapon  system.  Early 
weapon  system  development  decisions  directly  influence  the  software  life  cycle  through 
necessary  trade-offs  at  the  system  engineering  and  program  manager  levels.  Typical  design 
trade-offs  that  influence  the  software  life  cycle  include  operational  user  requirements  vs. 
maintenance  needs;  hardware/software  partitioning;  and  the  dominant  cost,  schedule  and 
performance  constraints. 

Software  is  very  often  the  ultimate  pacing  technology  in  weapon  system  development 
programs.  This  software  life  cycle  begins  with  a  system  concept  and  initial  program  formulation. 
Detailed  software  development  generally  occurs  late  in  the  weapon  system  development  cycle, 
and  is  generally  paced  by  the  design  and  development  processes  for  the  hardware  and 
architectural  configurations.  Evolving  weapon  system  needs  and  late  selection  of  hardware 
configurations  also  exacerbate  these  long  software  development  cycles.  It  is  not  uncommon  for 
the  software  design  process  to  extend  well  after  the  operational  testing  with  new  software  being 
implemented  as  “block  changes”. 

Software  is  perceived  by  DoD  as  offering  significant  opportunities  to  meet  changing 
requirements  as  deployed  software-intensive  systems  evolve.  For  example,  after  initial  system 
deployment  and  throughout  the  remaining  life  cycle,  it  is  generally  easier  and  less  costly  to 
modify  the  software  of  digital  computers  than  it  is  to  modify  analog  hardware  either  to  correct 
identified  problems  or  to  introduce  evolving  requirements.  The  Air  Force’s  experience  on  the 
F-lll  program  exemplifies  this  condition: 

The  Air  Force  upgraded  the  avionics  of  its  F-lll  A/E  aircraft  by  altering  their 
analog  (hard-wired)  computers.  It  also  upgraded  the  avionics  of  its  F-lll  D/F 
aircraft,  introducing  the  same  new  capabilities  by  altering  the  software  in  their 
digital  computers.  The  hardware  changes  cost  fifty  times  as  much  as  the 
software  changes  and  took  three  times  as  long  to  make.  [Canan,  86,  50] 

2.3  Significant  Trends 

DoD  weapon  systems  are  becoming  more  software  intensive.  Software  and  computer 
technologies  are  providing  the  essential  link  enabling  system  designers  to  integrate  various 
functions  into  system  designs  rather  than  having  to  implement  each  function  as  a  discrete 
subsystem.  These  new  technologies  also  provide  designers  with  unique  opportunities  to 
distribute  and  even  share  functional  elements  within  systems,  thereby  reducing  overall  size, 
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weight,  and  power  requirements  while  often  increasing  mission  capabilities.  The  tremendous 
growth  trend  in  software  requirements  is  illustrated  by  the  following  observation: 

Growth  in  the  numbers,  speed  and  power  of  the  embedded  hardware  has 
increased  the  length  and  complexity  of  the  software  used  to  run  the  computers. 

The  F-16D  has  236,000  lines  of  code,  versus  135,000  on  its  predecessor,  and  the 
500,000  lines  of  code  on  the  B-1A  bomber  introduced  in  1976  grew  to  1,387,000 
statements  on  the  B-1B  ten  years  later.  It  is  estimated  that  the  ATF  [Advanced 
Tactical  Fighter]  will  require  as  many  as  seven  million  lines  of  code  (and  the 
software  for  trainers  and  ground  support  will  add  another  three  to  five  million 
lines).  [Tenenbaum  1987, 3] 

The  extent  of  systems  software  requirements  growth  is  further  exemplified  by  the  April  7,  1988 
DoD  Inspector  General’s  report  on  the  Defense-wide  Audit  of  Support  for  Tactical  Software. 

The  cost  of  acquiring  and  maintaining  software  is  expected  to  grow  dramatically 
over  the  next  several  years.  An  Electronics  Industries  Association  Study 
developed  for  Congress  in  1980,  and  updated  in  1985,  estimated  that  mission- 
critical  computers  in  DoD  will  grow  from  approximately  10,000  in  1980  to  about 
350,000  in  1987.  Similarly,  the  cost  of  the  computers  for  military  applications 
was  projected  to  increase  from  about  $1  billion  annually  in  1980  to  about  $6 
billion  annually  in  1990  through  1995.  However,  the  software  acquisition  and 
maintenance  cost  for  the  computers  was  projected  to  increase  from  about  S3 
billion  in  1980  to  about  $29  billion  in  1990,  and  about  $42  billion  in  1995.  [OIG 
1988,  1] 

Commercial  Off-the-Shelf  (COTS)  software  and  computer  systems  will  meet  some  of 
DOD’s  requirements,  but  not  all  of  them.  The  commercial  software  sector’s  primary  focus  is 
different  and  generally  inadequate  to  meet  many  of  the  DoD  real  time  and  adaptive  weapon 
system  requirements.  The  workshop  participants  were  in  unanimous  agreement  with  the 
following  observation  of  the  Defense  Science  Board  Task  Force  on  Military  Software: 
“Mission-critical  military  software  is  more  universally  real-time,  communications-oriented,  and 
resource-constrained  than  its  civilian  counter  parts.  At  any  given  time,  the  demands  of  weapon 
systems  stress  the  state  of  the  software  art  more  severely  than  do  civilian  demands.”  [DSB,  Sept. 
1987,  7] 

The  growth  in  system  software  requirements  is  due,  in  part,  to  the  rapidly  advancing 
digital  microelectror'cs  technology.  These  microelectronic  advances  have  permitted  more 
functionality  to  be  u  --emeuted  within  the  specified  design  constraints.  This  increase  in  systems 
functionality  has  ■  rise  to  an  enormous  growth  in  software  production  demand.  In  order  to 
keep  pace  with  th.,*  ueinand  growth,  DoD  needs  to  address  improvements  in  technologies  which 
can  favorably  impact  in**  e  >ftware  development,  production  and  evolution  process. 

The  DoD  '.r’.ique  mission-critical  military  software  deployment  problems  will  be  further 
exacerbated  by  shortages  of  computer  and  software  specialists.  The  Government  versus  private 
sector  pay  differential  coupled  with  the  poor  training  programs  for  programmers  often  deters 
potential  applicants.  For  example,  an  entry  level  programmer  for  DoD  earns  just  a  little  over  15 
thousand  dollars,  whereas  an  entry  level  programmer  performing  the  same  work  in  the  private 
sector  will  earn  over  7  thousand  dollars  more.  This  resource  problem  will  continue  as  the 
demand  for  programmers  increases. 

For  some  time,  there  has  been  a  significant  shortage  of  computer  system  analysts  and 
computer  programmers  within  the  United  States.  The  Bureau  of  Labor  Statistics  predicts  an 
increase  in  this  shortage  for  the  1990s.  In  the  Projections  2000  bulletin,  published  in  March, 
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1988,  the  demand  for  computer  specialists  is  predicted  to  increase  by  60  to  85  percent  by  the  year 
2000.  This  increase  in  demand  could  be  even  more  pronounced  for  programmers  with  Ada 
backgrounds. 

Shortages  will  also  be  exacerbated  by  changing  demographics  and  college  student  career 
preferences.  The  last  of  the  “baby  boomers”  have  completed  college,  and  enrollment  is 
expected  to  decrease  by  more  than  5  percent  through  the  year  2000  according  to  the  Bureau  of 
the  Census.  In  addition,  between  1982  and  1986,  college  freshman  career  preference  for 
computer  science  fell  from  8.5  percent  to  4  percent  according  to  the  Higher  Education  Research 
Institute.  There  is  no  question  that  there  will  be  a  critical  shortage  of  computer  specialists 
throughout  the  next  decade.  [DOL 1988] 

2.4  DOD  Software  Technology  Programs 


This  section  of  the  report  provides  a  synopsis  of  ongoing  DoD  software-related 
technology  base  (or  technology-base  like)  programs.  The  information  was  included  if  the 
program  was  generic  in  nature  and  excluded  if  there  was  a  specific  (immediate)  application 
target. 


The  combined  Army,  Navy,  and  Air  Force  software-related  technology  base  efforts  for 
FY88,  FY89,  and  FY90  were  budgeted  at  S64.9M,  $75. 2M,  and  $69. 1M  respectively.  Since 
budget  and  programmatic  data  are  always  in  a  state  of  flux,  this  budgetary  information  is 
considered  current  only  as  of  July  1988.  The  source  data  for  these  summaries  were  the  briefing 
charts  from  the  Services’  Science  and  Technology  review  of  the  computer  and  software 
technology  base  programs  given  to  DOD  during  the  summer  of  1988. 

Three  other  high  visibility  DOD  programs  -  Ada,  the  Software  Engineering  Institute 
(SEI)  and  the  Software  Technology  for  Adaptable  Reliable  Systems  (STARS)  Program  -  are 
funded  at  approximately  $25.0M,  $18.8M,  and  $17.7M,  respectively  for  FY89. 

There  are  additional  software-related  development  efforts  under  the  specific  sponsorship 
of  Service  program  offices/ Agencies;  however,  the  effort  necessary  to  assemble  data  on  these 
other  software-related  programs  is  beyond  the  scope  of  this  study.  Therefore,  the  following 
summary  of  the  planned  FY89  of  SDIO  software  technology  base  budget  is  provided  as  an 
example  of  other  ongoing  Service/ Agency  efforts. 

a.  Software  Engineering  Environments  -  $4.0M 

b.  Trusted  Software  -  $5.2M 

c .  Distributed  and  Real-Time  Operating  Systems  -  $4 . 7M 

d .  Parallel  Programming  -  $3 .0M 

e.  Other  -  $1.9M 

The  workshop  participants  voiced  unanimous  concern  that  the  software  technology  base 
funding  was  not  keeping  pace  with  the  rapid  increases  in  software-related  acquisition  and 
maintenance  costs.  Workshop  discussions  focused  on  the  fact  that  participants  of  the  Services’ 
Science  and  Technology  review  observed  that  the  software-related  technology  base  funding  may 
be  over  estimated  by  between  10  to  50  percent  because  of  the  close  coupling  to  specific  computer 
hardware  development  and  acquisitions.  Even  at  these  possibly  inflated  funding  levels,  the 
combined  FY  89  software  technology  base  funding  allocations  will  be  less  than  0.3  percent  of  the 
anticipated  DoD  software  acquisition  and  maintenance  burden  of  $29  Billion  in  1990. 

2.5  Overview  of  Recent  Software  Studies 

Several  recent  software  studies  [DSB  1987;  Zraket  1988;  Nash  1988;  Druffel  88;  OIG  88] 
recognize  that  the  DoD  acquisition  and  management  policies  contribute  to,  and  even  induce, 
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many  of  the  current  software  deployment  and  operational  problems.  In  addition,  these  policies 
often  impede  attempts  to  resolve  critical  long  term  operational  problems  in  current  software 
intensive  weapon  systems.  There  was  no  single  problem  identified  in  these  studies  but  rather 
they  identified  a  series  of  problems  that  tend  to  be  repeated  over  and  over  again.  Table  R-l,  in 
Appendix  B,  summarizes  the  categories  of  the  identified  software  issues  addressed  in  these 
reports. 


3.  IDENTIFICATION  OF  HIGH  PRIORITY  SOFTWARE-INDUCED 
OPERATIONAL  PROBLEMS 

The  following  sections  address  DoD  software-related  problems  from  three  different 
perspectives:  operational  system  problems,  the  systems  acquisition  process ,  and  generic  software 
technology  areas.  These  problems  were  identified  by  the  workshop  participants,  and  are  based 
both  on  their  own  personal  operational  experiences  as  well  as  their  many  technical  interchange 
meetings  with  weapon  system  operators  and  military  commanders. 

The  workshop  participants  attempted  to  view  these  DoD  software  problems  from  a 
“user/commander”  perspective.  A  summary  of  the  military  software  deployment  problem, 
from  this  perspective,  follows: 

a.  There  are  growing  allegations  and  perceptions  that  software,  treated  in  its  broadest  sense, 
is  the  principal  flaw  degrading  the  performance  and  capabilities  of  many  of  our  most 
essential  military  and  intelligence  systems. 

b.  The  dependence  on  software  in  our  most  critical  military  and  intelligence  systems  is 
increasing,  not  decreasing. 

c.  The  dependence  on  software  is  increasingly  viewed  as  a  crippling  operational  problem 
because  (1)  operational  readiness  of  delivered  software  is  difficult,  if  not  impossible,  to 
certify;  (2)  software  delivery  seems  to  always  be  late;  (3)  documentation  is  marginal  for 
field  utilization;  and  errors  are  difficult  to  isolate. 

d.  Software  activities  needed  to  extend  the  life  of  weapons  systems  are  often  not  funded  with 
their  companion  equipment  upgrades.  Hence,  software  is  frequently  the  “named  culprit” 
in  life  extension  failures. 

Technology  advances  in  many  disciplines  (sensors,  microelectronics,  computers, 
software,  etc.)  have  permitted  designers  to  incorporate  higher  levels  of  system  complexity  and 
functionality  within  assigned  weight  and  volume  constraints.  These  technology  advances  have 
permitted  designers  to  cost-effectively  implement,  control  and  integrate  various  functional 
capabilities  with  software.  It  is  important  to  recognize  that  up  until  around  ten  to  fifteen  years 
ago  that  such  user-perceived  problems  would  have  focused  on  various  hardware  functions  that 
are  now  implemented,  controlled  and  integrated  with  software.  What  is  critical  in  this 
observation  is  that  currently  (and  for  the  foreseeable  future)  more  and  more  system  functionality 
is  directly  tied  to  software;  and  therefore,  a  higher  percentage  of  the  system  design  and  evolution 
problems  will  move  from  the  hardware  to  the  software-related  technology  domain.  This 
transitioning  trend  is  evident  in  the  three  different  perspectives  of  software-related  problems 
discussed  in  the  following  sections. 

3. 1  Operational  System  Problems 

This  section  of  the  report  takes  a  different  approach  from  the  many  studies  referred  to  in 
Section  2.5,  and  addresses  the  types  of  common  software  problems  directly  related  to 
deployment  of  operational  weapon  systems. 

Many  of  the  common  problems  may  be  attributed  to  one  of  software  technology’s  most 
desirable  properties.  Specifically,  software  technology  assists  in  weapon  system  evolutions  by 
permitting  gains  in  weapon  system  performance  and  provides  system  application  flexibility 
without  costly  hardware  configuration  changes.  Because  of  software’s  perceived  inherent 
adaptability,  military  commanders  are  often  impatient  to  introduce  software  changes  that  will 
permit  weapon  systems  to  address  new  threats,  apply  new  tactics,  or  accommodate  changing 
environments.  Therefore,  “user”  software  technology  concerns  usually  do  not  focus  on 
software  development  problems,  but  instead  focus  on  operational  weapon  system  evolution  and 
support  problems  that  adversely  impact  their  ability  to  (1)  rely  on  and  trust  the  system,  (2) 
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effectively  use  the  systems  in  conjunction  and  in  context  with  other  systems,  and  (3)  rapidly 
modify  the  systems  to  meet  changing  needs. 

The  user  must  have  confidence  that  a  software-intensive  system  will  work  the  intended 
way,  will  have  a  known  sustained  level  of  performance  over  time,  and  will  be  effective  when  used 
by  assigned  personnel.  This  high  level  of  confidence  in  the  system  must  be  sustained  at  a  high 
level  during  support  and  maintenance  of  the  weapon  system,  and  especially  as  new  software 
enhancements  are  introduced. 

Today’s  weapon  systems  must  function  effectively  in  context  with  other  systems  and  in 
rapidly  changing  environments.  The  software  systems  must  be  able  to  quickly  incorporate  the 
changes,  integrate  new  data,  compute  results  and  display  the  revised  situation  in  the  proper 
context  for  a  user  to  make  the  correct  tactical  decision  and/or  interoperate  with  other  s>slem°. 

Rapid  technology  advances  influence  the  designs  of  DoD  weapons  systems. 
Unfortunately,  similar  technology  finds  its  way  into  systems  of  potential  adversaries.  Therefore, 
the  field  commanders  and  weapon  system  operators  must  have  software  systems  that  are  flexible 
enough  to  evolve  with  changing  technology  and  operational  needs.  These  operational  software 
systems  must  also  possess  characteristics  that  make  them  easy  to  diagnose  and  isolate  faults, 
prescribe  corrective  actions  and  institute  system  fixes. 

An  outline  of  common  software  problems  clustered  in  terms  of  perceived  user 
operational  problems  was  developed  by  the  workshop  participants  and  is  presented  in  Table  B-2 
of  Appendix  B. 

3.2  System  Acquisition  Process 

This  section  of  the  report  attempts  to  isolate  the  “classic  problems”  that  influence 
software  deployment  and  are  associated  with  the  weapon  system  acquisition  process.  These 
software  problems  are  virtually  ubiquitous  across  software  intensive  systems  and  are  most 
frequently  associated  with  weapon  system  cost,  schedule  and  performance  constraints. 

Software  intensive  systems  are  often  initiated  with  an  inadequate  and  unrealistic 
understanding  of  the  basic  system  requirements,  software  requirements,  software  development 
costs,  and  associated  schedules.  System  requirements  tend  to  grow  as  users  and  developers  gain 
a  better  understanding  of  the  realistic  properties  and  capabilities  of  the  system  under 
development.  New  and  evolving  system  requirements  translate  to  additions  or  changes  in 
software  requirements,  thus,  further  exacerbating  the  growings  cost  and  schedule  problems. 
These  schedule  problems  are,  in  part,  due  to  the  fact  that  the  software  development  is  initially 
paced  by  the  hardware  and  architectural  development.  The  resulting  cost  growth  is  generally  due 
to  the  extended  schedules.  The  perception  of  software  cost  growth  problems  is  further 
exacerbated  when  system  designers  underestimate  workloads  due  to  a  lack  of  credible  software 
development  metrics. 

Development  teams  often  lack  (and  because  of  the  source  selection  process,  often  are  not 
chosen  for  their)  experience  and  expertise  in  advanced  software  and  computer  technology 
applications  areas.  Frequently,  DoD  focuses  on  hardware  contractors  as  opposed  to  system 
integration  contractors.  These  problems  are  usually  exacerbated  by  the  contractor  selecting  and 
freezing  the  hardware  configurations  before  specifying  the  software  (a  problem  compounded  by 
inadequate  interface  definition  and  coordination  between  the  various  hardware  and  software 
design  teams  which  are  often  separated).  Finally,  many  system  design  activities  fail  to  implement 
and  enforce  sound  software  development  standards  as  well  as  proven  design  methodologies. 
The  workshop  participants  felt  that  this  last  problem  is  influenced  in  part,  by  the  lack  of  DoD 
incentives  that  would  stimulate  software  productivity,  such  as  the  very  controversial  issue  of 
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The  September  1987  Defense  Science  Board  Task  Force  on  Military  Software  presented  a 
number  of  recommendations  addressing  a  wide  range  of  software-related  acquisition  problems 
(including  this  data  rights  issue).  A  follow-on  Workshop  on  Military  Software  was  specifically 
requested  by  the  Defense  Science  Board  Chairman  and  chaired  by  Mr.  Charles  Zraket  during  the 
summer  of  1988.  This  Workshop  report  strongly  endorsed  the  recommendations  of  the  Task 
Force  report  and  recommended  that  DoD  use  it  as  a  basis  for  the  long-term  management  of 
military  software  research  and  acquisition.  However,  to  date,  the  vast  majority  of  these 
software-related  acquisition  recommendations  have  not  been  implemented  by  DoD. 

3.3  Generic  Software  Technology  Areas 

There  was  a  general  perception  by  the  workshop  participants  that  many  of  the  identified 
software-related  deployment  problems  would  be  mitigated  if  additional  research  and 
development  efforts  were  focused  on  generic  software  technology  areas  that  transcend  specific 
program  requirements.  If  common  system  software  technology  requirements  could  be  identified 
early  enough,  potential  economies  of  scale  may  be  realized  by  clustering  research  efforts. 

Research  areas  would  need  to  be  at  a  high  enough  level  of  abstraction  to  cover  a 
significant  number  of  Service  requirements ,  yet  have  applicability  and  transferability  to  specific 
program  efforts.  Unfortunately,  the  workshop  participants  knew  of  neither  an  existing 
convenient  forum  (either  at  the  Services  or  DoD  levels)  for  identifying  the  generic  software 
technology  needs  nor  a  convenient  vehicle  for  reviewing  and  sharing  specific  software  technology 
advances  across  Services  and  system  program  offices. 

The  workshop  participants,  recognizing  this  dilemma,  attempted  to  identify  generic 
software  technology  areas  that  have  wide  applicability  to  specific  system  and  Service 
requirements  as  well  as  address  the  issues  and  problems  identified  by  the  workshop  (and 
summarized)  in  Tables  B-l  &  B-2.  An  unprioritized  listing  of  the  potential  generic  system 
software  technology  areas  identified  by  the  workshop  is  presented  in  Table  B-3  in  Appendix  B. 
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4.  FINDINGS  AND  RECOMMENDATIONS 


The  principal  findings  of  the  workshop,  as  they  relate  to  the  DoD’s  ability  to  deploy  and 
support  software  intensive  weapons  systems  are  listed  in  the  following  sections.  For  each  of  the 
findings,  specific  recommendations  are  provided  for  consideration  by  DDDRE(R&AT)  as 
potential  actions  to  improve  the  deployment  of  software  technology  in  weapon  systems. 

4.1  Deployed  Military  Software  Improvement  Programs 

4.1.1  Findings 

By  viewing  the  growing  software  problem  from  the  “user’s/commander’s”  perspective, 
the  workshop  participants  discovered  an  important  missing  ingredient  in  the  focus  of  DoD’s 
software  technology  base  programs.  An  overall  mechanism  to  support,  encourage,  and  expedite 
needed  military  software  improvements  during  weapon  system  deployment  is  lacking.  As  a 
result,  the  attainment  of  measurable  and  predictable  improvements  in  military  software  is 
seriously  inhibiting  weapon  systems  adaptability  and  evolvability,  and  adversely  impacting 
testability  of  software  intensive  systems. 

The  costs  of  using,  maintaining,  and  supporting  currently  deployed  software  intensive 
weapon  systems  are  excessive.  Cost  avoidance  opportunities  need  to  be  identified  and  exploited, 
especially  in  cases  where  advanced  software  and  hardware  retrofits  will  increase  reliability  and 
maintainability  while  reducing  operating  and  support  costs.  Workshop  participants  were 
convinced  that  small  investments  in  software  and  computer  technology  research  targeted  at 
deployed  systems  would  have  significant  pay-offs.  Furthermore,  the  vast  majority  of  software 
technology  advances  that  would  improve  DoD’s  operational  systems  software  deployment  will 
also  yield  a  commensurate  improvement  in  software  quality  and  productivity  for  new  systems. 
The  workshop  participants  felt  that  focusing  software  technology  research  and  development  on 
problems  related  to  deployed  systems  would  not  only  ensure  the  early  realization  of  both 
enhanced  system  software  performance  and  support  cost  avoidance  opportunities,  but  the 
software  technology  advances  would  be  more  acceptable  to  the  risk  conscious  program 
managers  since  there  would  now  exist  demonstrated  benefits. 

4.1.2  Recommendation 

The  DDDRE(R&AT)  should  establish  a  comprehensive  approach  for  improving  military 
software  during  deployment.  Focus  should  be  on  the  phases  of  the  “Software  Life  Cycle”  that 
have  the  most  influence  over  the  deployment  of  software  intensive  weapons  systems,  that  inhibit 
systems  software  adaptability/evolvability,  and  that  provide  the  most  leverage  in  attaining 
improved  operational  performance  (or  capability  per  unit  cost).  DoD  resources  should  be 
applied  to  those  software  problems  or  software  features  which  are  military  or  intelligence- 
specific  and  hence  cannot  depend  on  consumer  market  place  forces  to  drive  commercial  sector 
spending  in  research  and  engineering.  The  following  outlines  the  recommended  approach. 

a.  Dispatch  a  small  team  of  experts  to  discuss  the  software  problems  and  the  approaches 
proposed  in  this  document  with  military  operational  commands  to: 

1.  Validate  the  findings  and  approach  of  this  report, 

2.  Solicit  additional  concerns,  problems,  and  potential  high  pay-off  software  projects 
based  on  their  “hands-on”  experiences,  and 

3.  Obtain  willing  “user”  commitments  to  include  relevant  proposed  actions  in  the 
Command’s  program. 

b.  Refine  the  approach  and  recommendations  of  this  report  based  on  the  results  of  the  team 
visits  (Section  4.1.2  a). 


c.  Identify  a  few  high  priority  representative  software-intensive  military  or  intelligence 
systems  needing  improvement.  High  priority  project  opportunities  should  include  weapon 
systems  that  fall  in  the  procurement  (6.4,  6.5,  6.7,  etc.)  as  well  as  Program  2  and  3 
categories.  Software  problems  or  features  should  be  drawn  initially  from  the  development 
testing,  operational  testing,  and  maintenance  phases  of  the  software  life  cycle.  The 
underlying  objective  is  to  accelerate  advanced  software  applications  in  the  life  cycle  phases 
of  weapon  systems  where  the  majority  of  software  development,  upgrades,  modernization, 
test,  and  evaluation  are  now  funded  and  performed.  Recommended  approaches  include: 

1.  In  conjunction  with  the  visits  discussed  in  Section  4.1.2a,  the  small  team  of  experts 
should  ask  the  users  to  identify  critical  software  problems  and  related  high  pay-off 
software  projects.  For  these  identified  projects,  DDDRE(RAAT)  should  solicit  the 
support  of  operational  commands/commanders  in  the  form  of  statements  of 
requirements  (SORs)  and  their  continuing  support  as  informed  guaranteed 
customers. 

2.  DDDRE(R&AT)  should  task  the  Services  to  identify  software  intensive  systems 
currently  experiencing  operational  software-related  problems.  Based  on  these 
responses,  DDDRE(R&AT)  should  investigate  opportunities  to  use  the  Defense 
Acquisition  Board  (DAB)  Milestone  IV  and  Milestone  V  Reviews  as  a  forum  for 
identifying  potential  software  technology  test-bed  demonstration  projects. 

d.  Establish  several  high  pay-off  software  technology  test-bed  demonstration  projects  to  be 
conducted  by  each  of  the  Services.  The  objective  of  these  projects  should  be  to  develop 
processes,  procedures,  and  metrics  to  counter  current  software  deployment  problems. 

The  demonstration  projects  should  focus  on  upgrades  to  existing  operational  software 
intensive  weapon  systems  currently  experiencing  critical  software  difficulties.  The  goals  of 
the  software  technology  test-bed  demonstration  projects  would  be  (1)  to  establish  a 
baseline  metric  to  measure  software  technology  enhancement  results,  (2)  to  develop  an 
improved  maintenance  and  support  environment  for  the  existing  system,  (3)  to 
demonstrate  significant  (order  of  magnitude)  improvements  in  ability  to  maintain  and 
evolve  the  existing  system,  (4)  to  begin  to  apply  available  software  engineering  technology 
to  the  software  re-engineering  tasks  (as  opposite  to  “bug  removal”),  and  (5)  to  abstract  the 
results  from  the  experimental  projects  to  develop  an  approach  for  other  software  intensive 
systems. 

4.2  Software  Technology  Funding  Support  (Ongoing  Programs) 

4.2.1  Findings 

The  rate  of  software  technology  evolution,  although  advancing  moderately,  has  not  kept 
pace  with  DoD  weapons  systems  requirements  for  more  software  with  increasing  complexity, 
and  the  current  cost  of  software  maintenance  and  support  is  increasing  rapidly.  The  workshop 
participants  were  unanimous  in  their  conclusion  that  the  current  budget  for  software  technology 
is  not  commensurate  with  DoD’s  development,  deployment,  maintenance  and  support  needs  for 
software  intensive  weapons  systems.  They  felt  that  significant  increases  in  software  technology 
base  efforts  are  required  even  though  DoD  is  entering  an  austere  funding  period. 

4.2.2  Recommendation 

DDDRE(R&AT)  should,  as  a  minimum,  continue  to  fully  support  the  existing  ongoing 
software  technology  base  programs  including  Ada,  STARS,  the  SEI,  along  wuii  the  ongoing 
software  technology  development  efforts  at  DARPA  and  the  Service  Laboratories  in  the  face  of 
an  austere  budget.  Given  that  the  combined  DoD  FY  1989  Software  Technology  Base  funding 
allocation  will  be  less  than  0.3  percent  of  the  projected  $29  billion  DoD  software  acquisition  and 
maintenance  requirements  for  1990  (see  Section  2.4),  DDDRE(R&AT)  should  task  the  Services 


and  DARPA  to  specifically  reassess  their  software  technology  base  requirements  for  FY  1991. 
DDDRE(R&AT)  should  take  the  lead  in  ensuring  that  the  software  technology  base  funding 
priority  is  increasing  commensurate  with  the  rising  trend  of  software-related  deployment  and 
support  costs. 

4.3  Generic  Software  Technology  High  Priority  Efforts 

4.3.1  Findings 

Several  aspects  of  each  of  the  generic  software  technology  areas  highlighted  in  Table  B-3 
are  at  the  leading  edge  of  technology  development  and  are  uniquely  applicable  to  DoD  weapon 
systems.  Given  the  growing  significance  as  well  as  the  increasing  maintenance/support  cost 
burden  of  software  technologies,  the  workshop  concluded  that  DoD  needs  to  investigate 
opportunities  to  expand  the  focus  of  DARPA  and  the  Service  Laboratory  research  efforts  into 
all  of  these  generic  software  technology  areas.  The  workshop  participants  observed  that  neither 
the  Services  nor  DoD  had  in  place  a  convenient  forum  for  identifying  generic  software 
technology  needs.  DoD  lacks  a  convenient  vehicle  for  reviewing,  sharing  and  stimulating 
advanced  software  technology  applications  across  Services  and  system  program  offices. 

4.3.2  Recommendation 

DDDRE(R&AT)  should  task  the  Services  and  Agencies  to  establish  (one  or  more)  “lead 
ug.ent s”  for  selected  critical  software  technology  areas.  The  lead  agents  should  be  carefully 
selected  for  their  technical  expertise  in  advanced  software  and  mission  critical  computer 
technology  disciplines.  The  lead  agents  will  supplement  R&AT  expertise  and  help  maintain  a 
level  of  technical  currency  on  critical  software-related  issues  by  providing  an  annual  summary  of 
the  Services’  software-related  programs,  issues,  needs  and  problems.  The  primary  function  of 
the  lead  agents  will  be  to  help  identify  Service  software  technology  related  problems  and 
requirements  while  promoting  the  sharing  of  software  technical  information  and  stimulating 
advanced  software  technology  applications  across  Services  and  Program  offices. 

Software  technology  areas  that  are  currently  too  high  a  risk  for  specific  ongoing  programs, 
yet  have  the  potential  of  meeting  critical  DoD  system  requirements  of  the  future,  should  be  given 
high  DoD  priority  and  be  monitored  by  the  Service  lead  agents.  The  lead  agents  should  be 
delegated  the  specific  responsibility  of  assessing  and  identifying  critical  software  technology 
areas  that  have  targeted  application  potential  within  5  to  10  years.  Such  technology  targets 
should  be  supported  in  the  context  of  other  projected  Service  and  DoD  requirements.  The  lead 
agents  should  be  tasked  with  coordinating  critical  resources,  defending  the  software  technology 
base  budget  requirements,  promoting  software  technology  transition  opportunities,  and 
providing  a  status  briefing  to  DDDRE(R&AT)  on  an  annual  basis.  As  a  start,  the  lead  agents 
should  begin  by  focusing  on  the  list  of  generic  software  technology  areas  identified  in  Table  B-3. 

4.4  Recommendations  of  Previous  Studies 
4.4.1  Findings 

One  of  the  most  discouraging  findings  of  the  workshop  was  the  lack  of  significant  and 
consistent  action  on  the  recommendations  of  numerous  “Software  Reports”  commissioned  by 
DoD  policy  officials  in  the  recent  past. 

The  software-related  problems  associated  with  developing,  deploying  and  supporting 
software  intensive  DoD  systems  are  well  documented.  There  are  numerous  software  studies 
sponsored  by  the  Services,  DoD  and  the  GAO.  Nearly  every  one  of  these  studies  implies  that 
the  consequences  associated  with  the  DoD  software-related  technical  and  management 
problems  are  growing.  One  of  the  more  recent  studies  commissioned  by  DoD  was  the  Defense 
Science  Board  Task  Force  on  Military  Software.  The  workshop  participants  were  unanimous  in 
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their  opinion  that  this  effort  provided  a  comprehensive  review  of  DoD’s  software-related 
problems,  and  that  the  findings  and  recommendations  were  still  current  and  valid.  This 
observation  is  in  total  compliance  with  the  results  of  the  follow-on  “Workshop  on  Military 
Software”  conducted  at  the  request  of  the  chairman  of  the  Defense  Science  Board.  The  cover 
letter  transmitting  the  results  of  this  workshop  stated  that  they  “strongly  endorse  the 
recommendations  of  this  report  and  recommend  that  DoD  use  it  as  a  basis  for  the  long-term 
management  of  military  software  research  and  acquisition.” 

4.4.2  Recommendations 

DDDRE(R&AT)  should  use  the  Science  &  Technology  Committee  of  the  Defense 
Acquisition  Board  to  review,  sponsor,  and  promote  full  implementation  of  the  recommendations 
that  resulted  from  the  September  1987  Defense  Science  Board  Task  Force  on  Military  Software. 

4.5  DoD  Software  Responsibility  and  Authority 

4.5.1  Findings 

One  of  the  critical  problems  which  has  been  identified  in  almost  every  study  of  DoD 
software  problems  has  been  the  lack  of  any  single,  responsible  official  or  spokesman  for  military 
software.  The  November  1982  Defense  Science  Board  Task  Force  on  Embedded  Computer 
Resource  (ECR)  Acquisition  and  Management  concluded  that  there  was  no  consistent 
management  approach  across  the  OSD  Staff  and  the  Military  Departments  relating  to  software 
and  computer  technology.  From  1976  up  to  the  time  of  this  Defense  Science  Board  report,  OSD 
had  been  relying  on  the  DoD  Management  Steering  Committee  for  Embedded  Computer 
Resources  (MSC-ECR)  to  address  the  common  computer  and  software  problems.  This  Task 
Force  report  stated  that: 

OSD  has  attempted  to  manage  this  ever-growing  portion  of  its  business  through 
an  ad  hoc  committee  approach.  The  magnitude  of  the  complex  and  interrelated 
issues  to  be  resolved  in  this  area  have  clearly  outgrown  this  approach.  We  feel  it 
is  time  to  recognize  the  need  for  a  meaningful  approach  which  places 
responsibility  in  a  line  function.  [DSB,  1982,  54] 

As  a  direct  result  of  this  Task  Force,  the  MSC-ECR  was  discontinued  and  action  was  taken  to 
centralize  software  and  computer  acquisition  management  within  the  Office  of  the  Under 
Secretary  of  Defense  for  Research  and  Engineering.  Subsequent  to  this  time  frame,  however, 
DoD  has  undergone  several  organizational  changes  that  have  basically  reversed  this 
centralization  trend.  At  present,  DoD  software  and  computer  advanced  technology 
development,  acquisition  management,  test  &  evaluation,  policy,  and  the  software  intensive 
systems  maintenance  and  support  responsibilities  are  fragmented  over  a  range  of  OSD  offices. 
Quite  unintentionally,  DoD  has  been  conveying  an  erroneous  message  that  the  relative  priority 
reserved  for  software  and  computer  technology  has  decreased  since  the  1982  Defense  Science 
Board.  The  workshop  participants  felt  that  this  perception  is  further  perpetuated  by  both  the 
fragmentation  of  responsibilities  and  the  implementation  of  ambiguous  software  acquisition 
policies. 

Furthermore,  the  workshop  participants  observed  that  most  DoD  contracts  are  void  of 
contractual  incentives  which  might  stimulate  the  software  systems  engineer  to  design  in  long¬ 
term  supportability  and  maintainability  features.  Software  maintainability,  robustness, 
flexibility,  modularity,  and  testability  are  very  seldom  specified  as  system  or  procurement 
requirements.  At  present,  operational  support  problems  for  mission  critical  computer  software 
embedded  in  DoD  weapon  systems  are  growing,  while  at  the  same  time  DoD  management  and 
policy  formulation  are  fragmented.  The  following  is  only  a  partial  list  of  specific  software-related 
areas  needing  urgent  direct  DoD  management  oversight  and  evolving  implementation  policy: 


standards,  rights-in-data,  common  languages,  common  interfaces,  metrics,  prototyping,  reuse, 
and  contractual  incentives.  These  are  all  problems  that  transcend  Service/ Agency  requirements 
and  need  to  be  addressed  in  a  forum  that  will  allow  these  issues  and  problems  to  be  identified 
and  resolved. 

4.5.2  Recommendations 

DDDRE(R&AT)  should  become  an  advocate  for  and  begin  an  initiative  to  consolidate 
DoD  software  and  computer  policy,  management,  and  oversight  within  a  structured  forum  that  is 
commensurate  with  software  technology’s  growing  importance.  This  forum  should  provide 
direct  centralized  focus  on  the  growing  number  of  software-related  common  DoD  policy, 
programmatic  and  budget  issues  that  transcend  specific  Service  programs. 

Within  the  Office  of  the  Under  Secretary  of  Defense  (Acquisition),  (OUSD(A)),  resides 
all  of  the  functional  areas  (with  both  responsibility  and  authority)  necessary  to  address  the 
current  mission  critical  and  embedded  computer  software-related  problems.  The  following  are 
several  recommendations  developed  during  the  workshop  that  take  this  fact  into  account  and 
specifically  address  this  very  complex  software-related  responsibility  and  authority  problem: 

a.  The  workshop  participants  recommended  that  DDDRE(R&AT)  become  an  advocate  for 
and  begin  an  initiative  to  establish  a  Director  for  Military  Software  Improvement  within  the 
OUSD(A).  This  can  be  done  by  creating  a  new  position  or  assigning  an  existing  staff 
member  this  responsibility  and  associated  authority.  If  it  resides  within  an  existing  Staff 
Office,  the  principal  must  be  given  direct  line  access  to  OUSD(A)  to  resolve  software- 
related  conflicts.  The  Director  of  Military  Software  Improvement  should  be  established 
with  a  “sundown  clause”  stating  that  the  position  (or  assignment)  will  remain  in  effect  for  a 
period  not  to  exceed  three  years.  The  presence  of  a  sundown  clause  will  permit  unique 
working  relationships  across  OUSD(A)  Staff  functional  lines.  The  sundown  clause,  will  in 
effect,  establish  a  finite  schedule  as  well  as  a  compelling  goal  to  formulate  a  workable 
solution  that  equitably  addresses  the  many  concerns  across  DoD  functional  lines. 

During  this  period,  the  Director  of  Military  Software  Improvement  should  be  designated  as 
the  Officer  of  Primary  Responsibility  (OPR)  for  identifying,  managing,  integrating  and 
implementing  software  development,  acquisition  and  deployment  policy.  The  Director  of 
Military  Software  Improvement  should  also  be  designated  as  the  principal  advisor  to  the 
Defense  Acquisition  Board  (DAB)  on  all  matters  involving  computer  and  software 
technologies. 

b.  DDDRE(R&AT)  should  advocate  and  begin  an  initiative  to  establish  a  DoD  Management 
Steering  Committee  for  Military  Software  Deployment  Improvement  (MSC-MSDI)  similar 
to  the  previous  MSC-ECR.  It  should  operate  under  the  co-chairmanship  of  the  Director  of 
Defense  Research  &  Engineering  (DDRE)  and  the  Assistant  Secretary  of  Defense 
(Production  and  Logistics)  (ASD(P&L))  with  representation  from  the  Service  Assistant 
Secretaries  and  USD(A)  or  his  designate.  Placing  it  under  this  co-chairmanship  should 
eliminate  the  earlier  concern  that  the  MSC-ECR  failed  to  focus  management  attention  at  a 
high  enough  level.  It  will  provide  a  direct  forum  for  addressing  policy  and  program  issues 
that  transcend  Service/Agency  requirements.  The  MSC-MSDI,  in  conjunction  with  the 
recommended  DDDRE  (R&AT)  led  initiative  to  accelerate  software  deployment  (Section 
4.1.2),  should  be  recognized  as  the  principal  mechanism  for  planning,  programming  and 
budgeting  of  resources  that  may  fall  outside  the  Tech  Base.  The  MSC-MSDI  should  work 
in  close  conjunction  with  those  Service  Program  Managers/Program  Directors  investing 
heavily  in  high  priority  software  intensive  system  procurements. 

c.  Until  such  time  that  the  organizational-related  software  responsibility  and  authority 
problems  are  resolved,  DDDRE(R&AT)  should  take  the  lead  in  developing  and 


distributing  a  software  responsibility  and  authority  guide.  The  intent  of  the  guide  should  be 
to  permit  a  greater  understanding  of  the  current  software  policy,  review,  coordination  and 
oversight  responsibility  within  DoD. 
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APPENDIX  B 


Tables  of  Software  Issues,  Common  Problems  and 
Generic  Areas  With  Application  Potential 


1.  CATEGORIZATIONS  OF  SOFTWARE  ISSUES 

DoD  is  continually  asking  what  are  the  software  problems  and  how  may  they  be  resolved. 
The  SEI  observed  that  “There  is  no  single  problem,”  but  a  series  of  problems  that  tend  to  be 
repeated  over  and  over  again.  The  following  table  summarizes  software  issues  addressed  in 
recent  reports  (DSB  87;  Zraket  88;  Nash  88;  Druffel  88;  OIG  88]. 

Table  B-l.  Categorization  of  Software  Issues 

•  Production  Environment 
—  Lack  of  methods 

—  Lack  of  support  tools 
—  Failure  to  reuse  software 
—  Insufficient  capital  investment 

•  Life  Cycle 

—  Ineffective  management  of  life  cycle  activities 
—  Difficulty  measuring  and  estimating  cost,  quality,  and  productivity 
—  Poor  requirements  definition  and  analysis 
—  Continuing  software  acquisition  problems 
—  Limited  technology  transition 

•  Technical  and  Management  Professionals 
—  Lack  of  qualified  personnel 

—  Inadequate  training  and  education  opportunities/ services 

•  Software  Product 

—  Failure  to  meet  needs 
—  Failure  to  operate  correctly 


2.  COMMON  SOFTWARE  PROBLEMS  CLUSTERED  IN  TERMS  OF 
PERCEIVED  USER  OPERATIONAL  PROBLEMS 

The  workshop  participants  attempted  to  address  the  various  types  of  common  software 
problems  related  to  deployment  of  operational  systems.  The  following  table  is  an  outline 
developed  by  the  workshop  participants  to  summarize  common  software  problems  in  terms  of 
perceived  user  operational  weapon  system  problems. 
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Table  B-2.  Common  Software  Problems  Clustered  in  Terms  of  Perceived  User  Operational 
Problems 


•  Assurance  that  the  System  Meets  the  Operational  Needs 

—  Ability  to  test  the  software 

—  Ability  to  explain/define  system  software  requirements 

—  Ability  to  quickly  satisfy  new  and  evolving  requirements 

o  Characteristics  of  correctness,  availability,  performance  and 
security 

o  Ease  of  use 

—  Ability  to  “fail-safe”  or  “fail-soft” 

•  Assurance  that  the  System  Works  in  Context  with  Other  Systems 

—  Ability  to  interoperate 

—  Ability  to  rapidly  set-up  and  link  to  other  sites 

•  Assurance  that  the  System  can  Meet  Changing  Needs 

—  Ability  to  keep  systems  operational 
o  Rapidly  diagnose  problems 

o  Understand  effects  of  changes 

—  Ability  to  change  functions 

o  Responsive  to  evolving  requirements 
o  Timeliness  of  change 

—  Accessibility  of  software  resources 
o  Qualified  people 

o  Maintenance  and  support 


3.  GENERIC  SOFTWARE  TECHNOLOGY  AREAS  WITH  WIDE 
APPLICATION  POTENTIAL 

The  workshop  participants  attempted  to  identify  generic  software  technology  areas  that 
have  wide  applicability  to  system  and  Service  requirements  yet  might  not  be  justified  (in  terms  of 
return  on  investment)  for  a  single  specific  program.  Also  included  in  the  summary  of  generic 
software  technology  areas  are  research  and  development  efforts  that  have  the  potential  of 
addressing  the  issues  and  problems  identified  by  the  workshop  participants  in  Tables  B-l  and  B- 
2.  The  following  is  an  unprioritized  listing  of  potential  generic  system  software  technology  areas 
that  should  receive  increased  emphasis  and  consideration  by  DoD. 
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Table  B-3.  Generic  System  Software  Technology  Areas 


•  Software  Testing  Technologies 

•  Configuration  Management/Version  Control  Management  Tools 

•  Software  Modularity  and  Reuse  Standards 

•  Software  Prototyping  Concepts  &  Tools 

•  Software  Metrics 

•  Compiler  Instrumentation  and  Optimizations 

•  Software  Reverse  Engineering  Tools 

•  Object  Oriented  Programming  Tools 
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